Review of PR #19505: Narrow overload-error and symbol-use ranges to terminal identifier

Summary

This PR addresses two longstanding issues:

• #14284: FS0041 overload-resolution errors covering the entire expression (e.g., T.Instance.Method("")) instead of just the method name
• #3920: FSharpSymbolUse ranges reported through the name-resolution sink covering the full dotted long-identifier span instead of the terminal identifier

The approach introduces a dual-range design in ComputeItemRange — separating the structural itemRange (for typed-tree construction) from the narrow itemIdentRange (for diagnostics and IDE symbol reporting). This is well-designed and addresses both issues cleanly.

Strengths

1. Clean dual-range separation: ComputeItemRange returning (itemRange, itemIdentRange) is a principled design that keeps expression ranges intact for the typed tree while narrowing only the user-facing diagnostic/IDE surfaces.

2. Defensive error-narrowing guards in TcMethodApplication: The three conditions — single-line check, methodName.Length < itemWidth, and DoesIdentifierNeedBackticks — correctly handle edge cases:

   • Multiline expressions where column arithmetic would be wrong
   • Generic constructors with internal names longer than source text (e.g., ImmutableStack1 vs ImmutableStack)
   • Backtick-escaped identifiers where methodName.Length doesn't account for delimiters

3. Thorough test coverage: 7 new regression tests covering static, instance, chained, lambda, backtick, and multiline cases, plus extensive baseline updates across 35+ test files.

4. ServiceParamInfoLocations.fs adaptation: The getLeafFuncExpr helper with the not isInfix guard correctly compensates for narrowed symbol-use positions without breaking infix operator resolution.

Observations / Discussion Points

1. _mItemIdent in TcItemThen (line 8883): As @abonie noted, this parameter is passed through the 6-tuple but immediately discarded. It's carried because ResolveLongIdentAsExprAndComputeRange returns it and TcLongIdentThen passes the full result through, but TcItemThen itself doesn't need it — the narrowing happens either at the sink level (NameResolution.fs) or at the error level (TcMethodApplication). This is correct but adds structural noise. If there's no planned future use within TcItemThen, consider decomposing the result tuple before the call site (in TcLongIdentThen and TcTypeItemThen) to avoid propagating the unused field. Not a blocker.

2. ComputeItemRange when rest <> []: When resolution consumes only a prefix (e.g., System.DateTime from System.DateTime.Now), itemIdentRange falls back to itemRange (the whole consumed prefix range). Ideally this could narrow to the last consumed identifier (e.g., just DateTime), but since the remaining identifiers are resolved separately via TcLookupThen → ResolveExprDotLongIdentAndComputeRange, this is benign — the terminal Now gets its own narrow range in the subsequent resolution call. The PR is conservative here and doesn't regress this case.

3. getLeafFuncExpr performance: This recursive helper traverses the curried application spine on every VisitExpr callback. For deeply nested curried calls (e.g., f a b c d e), this is O(n) per visit. In practice this should be fine since application depth is bounded by typical code, but worth noting.

4. @auduchinok's upstream question: The open discussion about whether mItem should be computed differently at an earlier stage (rather than trimming at TcMethodApplication) is a valid architectural concern. This PR takes a pragmatic approach: it does the principled narrowing at the ComputeItemRange level for symbol-use sinks (#3920), while applying a targeted error-range fix at TcMethodApplication for overload errors (#14284). Both are useful independently. The deeper refactoring of how mItem flows through the checker could be a follow-up.

Verdict

The changes are correct, well-guarded, and thoroughly tested. The dual-range design is a clean solution that avoids disrupting typed-tree expression ranges while improving diagnostic and IDE precision. The open review comments are non-blocking discussion points rather than correctness issues.